Managing Requests

In any organization, there is usually a defined procedure which people must follow in order to implement change – this process may consist of more than twenty steps or may even require approval from some form of management. Workflow is a term used to describe any change process, outlining the necessary tasks and approvals required for its completion. Examples of change which may exist in an organization include the following:

  • An employee entering the organization
  • An employee leaving the organization
  • Replacing an entire computer network
  • Booking a plane ticket for business travel
  • Implementing an upgrade to a piece of hardware

Workflow management is the practice of ensuring all changes within an organization are carried out in a planned and authorized manner. It is a component of quality frameworks such as ISO 9001, BS 8018, ISO 20 000 and ITIL (Information Technology Infrastructure Library).

Within workflow management, all workflows are implemented following a Request for Change (RFC).

Lifecycle of a Request

Requests are created when change is required, for example when you must implement a workaround to resolve a call logged at the Service Desk. When a request is created, the appropriate template, including predefined attributes and a dependency diagram linking all tasks and approvals, must be selected.

Given the lifecycle of a request and the high number of requests which must be created in order for change to occur, it is important to use the appropriate system tools in which to monitor and keep track of all requests and tasks currently taking place. vFire Core enables analysts with the appropriate security permissions to effectively create, authorize, observe and report on every change request throughout its lifecycle.

vFire Workflow Management

vFire Workflow Management provides an automated means in which to design systematic and comprehensive procedures that will be implemented when change is required. Workflows for each request are displayed in a graphical format, allowing you to easily see the tasks, approvals and any dependencies required to implement the given change.

You can:

  • Create requests for change
  • Schedule a change request to occur at a future date and time
  • Create comprehensive workflows with the vast array of task entities in the drag-and-drop workflow builder on the dependency diagram
  • Create amendable requests by introducing amendable statuses. This will allow users to create their own service bundle contents in the portal
  • Create post provision actions, allowing users to add further functionality to a service that has already been provisioned
  • Use activation rules to automate and streamline any workflow
  • Generate reports regarding the details of a request and all its associated tasks
  • Define phases of a request, so that the tasks within can be grouped logically
  • View the progress of a request in the form of a Gantt chart
  • Use Gantt chart functionality to compare the planned and actual progress, time and expenses of a request
  • Export the progress and details of a request to Microsoft Project

Essentially, you can monitor and handle all requests and tasks associated with change for improved, consistent and predictable results. By streamlining your change processes, you are contributing to providing a system which is not only systematic but entirely traceable, leading to lower costs and shorter cycle times through a more effective use of resources.

Activating, Closing and Re-opening Tasks

Note the following rules dictating when tasks are activated, closed and re-opened.

  • A task is activated if all of its parent tasks are closed (except where the parent task is also a child task) and one of the paths is active.
  • A task will be closed redundant if its parents are in a state where they cannot activate the task. Normally this is where there is a single parent task that is closed redundant or rejected, but can also exist in more complex workflows like activation tasks not being able to meet the activation criteria.
  • A task will be reopened recursively provided it is not a type of task that has a conditional outcome. For example, the workflow will not reopen after an Approval, Conditional Branching Task, Manage CMDB Task or Outbound Action task.